Fix issue with sync watermark divergence - #5

Container-side filesystem writes were not making it back to the durable object after the first exec. A burst of printf > /workspace/foo.txt calls each succeeded inside the container but the host's ws.fs.readFile returned ENOENT for every file after the first. Once a workspace fell into this state, subsequent execs could not pull the missing entries even though the bytes were in wsd's store.

The root cause was a loopback-suppression optimization inside applyChanges. After applying an upstream batch the apply path advanced the local pushRev to the post-apply currentRev, moving it past entries the container had no way to know we had shipped. The container's fetchRev stayed where the last real push put it. The cross-side invariant check inside pullOnce then tripped on the next pull, the exec bracket swallowed the error, and fetchRev could no longer advance.

sequenceDiagram
  participant DO
  participant Container
  Note over DO,Container: before — pushRev advanced locally
  DO->>Container: push (senderRev=N)
  Container-->>DO: appliedPushRev=N
  Note over DO: applyChanges (upstream)<br/>local rev bumps to N+1<br/>pushRev = N+1 (local advance)
  DO->>Container: fetchChanges
  Container-->>DO: appliedPushRev=N, currentRev=N+1
  Note over DO: assert N >= N+1 — fails<br/>caught silently, fetchRev frozen

  Note over DO,Container: after — pushRev stays put
  DO->>Container: push (senderRev=N)
  Container-->>DO: appliedPushRev=N
  Note over DO: applyChanges (upstream)<br/>local rev bumps to N+1<br/>pushRev stays at N
  DO->>Container: push (senderRev=N+1, redundant entries)
  Note over Container: alreadyApplied drops them<br/>fetchRev = N+1
  Container-->>DO: appliedPushRev=N+1
  DO->>Container: fetchChanges
  Container-->>DO: appliedPushRev=N+1, currentRev=N+2
  Note over DO: assert N+1 >= N+1 — passes

The fix has two parts. Stop advancing pushRev locally on upstream apply: the receiver's alreadyApplied check drops the redundant entries on the next pushOnce and the container's fetchRev catches up in the same round trip. The cost is one extra push per upstream apply, bounded by the batch. Make pullOnce recover inline when a divergence does occur: cancel the stream, reset the divergent cursor to zero, retry once. A second divergence after the retry still surfaces via the existing assertion.

Unit tests cover both halves. The dofs apply suite pins the new contract: pushRev stays put on upstream apply, the next coalesce surfaces the apply's rev bumps, and the receiver's idempotence does the rest. The rpc suite pins the inline recovery: a one-shot lying remote triggers a reset and the retried call drains normally; a persistently lying remote degrades to a baseline re-sync rather than throwing.